A few years ago, different service types used different network protocols and often different proprietary software to delivery content, such as video, over a network. As content delivery and associated services have exploded on the Internet, Content Delivery Networks (CDNs) have had to scale accordingly. To make this expansion economical, there has been a tendency to reduce the number of protocols and server types in use to the point where virtually every non-real time application and even some real-time applications use HTTP.
The challenge with this rationalisation is that the generic nature of HTTP, in conjunction with the underlying TCP protocol, means that there is no way to share network resources in a way that is sensitive to the application requirements. For example, video streaming is likely to require very different bandwidth requirements to a file download.
Over-demand of bandwidth is dealt with very differently depending on the network. On a typical fixed broadband network, a packet scheduling algorithm called ‘Fair Queuing’ results in each access line getting an equal share of the available bandwidth when there is congestion. However, there is no network-based sharing mechanism for the traffic competing on a single access line. In this latter case, the dynamics of the transport protocol and the service will determine the share of access line capacity that each session gets, without any consideration of the requirements of each session.
In the past, with relatively slow access speeds, there has been a need to manage multiple services on a single access line, as users would run a small number of applications at a time and they would be aware of the limitations of the access network. In this situation, the principle of TCP friendliness where packet send rates are adjusted in response to congestion in the same manner for all sessions, copes as a resource sharing mechanism, albeit somewhat inefficiently.
However, as higher bitrate access technology is rolled out, customers will expect to be able to consume many services simultaneously. With no explicit way of controlling the share of network capacity amongst different streams or applications, the overall customer experience might fall short of customer expectations. The radically different bandwidth demands of different services mean that the principle of TCP friendliness is unlikely to result in a good customer experience.
To share bandwidth in a way that is dependent on the individual service, network operators can introduce network Quality of Service (QoS), which gives priority to packets that are marked appropriately. This allows prioritisation over the backhaul network and on the individual access line.
However, in practice network QoS is rarely used. It is complex to integrate with services, as they need to be authenticated by the network to ensure that are allowed to prioritise their traffic. More complex systems may require sessions to be set up to reserve capacity. Accounting and billing is also more complex. Each network operator will deploy their own QoS system, and so a national or international service provider will have to go to great expense to integrate many different operators' QoS systems and have an independent commercial relationship with each. For these reasons, QoS is rarely used for services other than those provided by the network operator itself. Even then, it is questionable as to whether it is cost-effective.